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Abstract 

The work achieved in multi-agent interactions design 
mostly relates to protocols definition, specification, etc. In 
this paper we tackle a new problem, the dynamic selection 
of interaction protocols. Generally the protocols and the 
roles agents play in protocol based interactions are imposed 
upon the system at design time. This selection mode severely 
limits the system 's openness, the dynamic behaviours agents 
can exhibit, the integration of new protocols, etc. To address 
this issue, we developed a method which enables agents to 
select protocols themselves at runtime when they need to 
interact with one another. Regarding the conditions which 
hold in the MAS agents can either jointly perform the selec- 
tion or individually. We define the concepts and algorithms 
which enable agents to perform this dynamic selection. We 
also describe the mechanisms which help agents anticipate 
interaction inconsistencies. 



1 Introduction 

Generally, the interaction protocols which support agents 
collaborative tasks' execution are imposed upon multi- 
agent systems (MAS) at design time. This static protocols 
selection severely limits the system's openness, the dy- 
namic behaviours agents can exhibit, the integration of 
new protocols, etc. For example, consider a collabora- 
tive task which can be executed following varied methods 
either by means of a Request protocol [5] (an identi- 
fied agent exhibiting specific skills is requested to per- 
form the task) or a Contract Net protocol (CNP) [6] (a 
competition holds between some identified agents in or- 
der to find out the best one to perform the task). Since 
the MAS is open and CNP looks for the best contrac- 
tor, it will undoubtedly be preferred to Request for such 
a task in absence of constraints such as execution de- 
lay. Thus, selecting Request at design-time prevents the ini- 
tiator agent from benefiting a better processing of this 



task. Moreover, the set of protocols used in multi-agent in- 
teractions is increasingly enlarging, and a static proto- 
col selection will only consider the protocols the designer 
knows even if these agents have the capacity of inter- 
preting and executing other protocols unknown at de- 
sign time. To overcome this limitation, we should enable 
agents to dynamically select protocols in order to inter- 
act. 

As yet, there have been some efforts [1, 4] to enable 
agents to dynamically select the roles they play during inter- 
actions using Markov Decision Processes, planning or even 
probabilistic approaches. However, they don't suit protocol 
based coordination mechanisms. Indeed, as protocols are 
partially sorted sequences of pre-formatted messages ex- 
change, selecting them to execute a task requires that their 
descriptions match that of the collaborative task. The solu- 
tions proposed so far do not explicitly focus on protocols 
and do not check such compliance either. To address this 
void, we developed a method which enables agents to dy- 
namically select protocols and roles in order to interact. Our 
method puts the usual assumptions about multi-agent inter- 
actions a step further. First, we consider that some interac- 
tion protocols can be known only at runtime. Thus, start- 
ing from a minimal version, agents interaction models can 
grow up by integrating these protocols from safe and au- 
thenticated libraries of interaction protocols when needed. 
Second, we consider that agents may have different design- 
ers, therefore they may encompass different protocols spec- 
ification formalisms. Furthermore, an interaction protocol 
is a triple {R, M, fi} where R is a set of interacting roles 
which can be of two types: initiator and participant. An ini- 
tiator role is the unique role in charge of starting the proto- 
col whereas a participant role is any role taking part in the 
protocol. Consequently, an initiator agent will be any agent 
playing the initiator role in an interaction while a partici- 
pant agent will be any agent taking up a participant role. In 
addition, protocols used in MAS can be classified 1 in three 
categories: (1) 1-1 protocols, which are protocols made of 



1 A complex protocol can be a combination of these basic categories. 



two roles (initiator and participant) both of them having 
only one instance (ex Request); (2) 1-1 N protocols, again 
protocols made of two roles with several instances of the 
participant (ex CNP); (3) 1-N protocols, which are protocols 
with several distinct participant roles each of them having 
only one instance (ex an auction protocol with one buyer, 
one seller and one manager). Subsequently, we define the 
dynamic protocols selection process for each of these cate- 
gories. 

Rather than explicitly indicating the protocols and the 
roles to use for all the agents which will execute the de- 
sired interaction, we suggest that agents programmers sim- 
ply mention the collaborative task's description in the ini- 
tiator agent's source code. As soon as an agent locates such 
a description, it identifies some potential participant agents 
and thereafter fires the dynamic protocol selection process 
taking up the initiator role. We assume that the MAS is pro- 
vided with potential participant agents identification proce- 
dures. Agents can dynamically select protocols in two pos- 
sible ways. First, the initiator agent and all the potential 
participant agents collectively select a protocol and assign 
roles to each agent inside this protocol. This is the joint pro- 
tocol selection method which assumes that agents trust one 
another and that they don't dread publishing their knowl- 
edge and preferences. On the other hand, agents can individ- 
ually select protocols and roles and start the desired interac- 
tion. This is the individual protocol selection method which 
assumes that agents do not trust one another and/or the sys- 
tem is heterogeneous (several sub systems with different 
protocol formalisms are plugged together). In this method, 
as the selected roles may mismatch, agents should antici- 
pate errors in order to guarantee consistent messages ex- 
change. We focus on wrong message structure error which 
indicates that something is wrong in the message structure 
(performative, content, language, ontology, etc.) and wrong 
message content error which indicates that the message's 
content doesn't match the expected content pattern. We ar- 
gue that our method introduces more flexibility in protocols 
execution, fosters agents autonomy, favours their dynamic 
behaviours and suits MAS' openness. In this paper we de- 
scribe both methods and detail their principles, concepts 
and algorithms. We exemplify them towards a web docu- 
ments filtering MAS composed of (1) query agents repre- 
senting the queries users formulate, (2) document agents 
representing the documents retrieved from the web, (3) and 
rule agents corresponding to any linguistic rule invoked to 
compute documents attributes (author (s), content, 
language, etc.). 

The paper is organised as follows. Section 2 formally de- 
fines the protocols selection problem. Sections 3 and 4 de- 
tail our methods. Section 5 discusses some related work and 
section 6 draws some conclusions. 



2 Problem Description 

Our purpose in this research, is to ease protocols defini- 
tion, implementation and use. Thus, we claim to free agents 
programmers from hard coding the protocols and the exact 
roles to use every time their agents have to execute a col- 
laborative task. Rather, they should only mention in the ini- 
tiator agent's source code the description of the collabora- 
tive task to execute. Then, once an agent comes across such 
a description, it will launch the dynamic selection process 
implicating potential participant agents. Concretely, given 
a collaborative task tj which is to be executed by a set 
A = {a\, d2, . . . flfe} of agents, the selection problem is 
stated as how an agent can select a protocol and a role in- 
side this protocol to execute tj7 It consists in finding out a 
protocol p and the roles r 1 ,r 2l ■ ■ .r p each a; should be en- 
acting in this protocol in order to get tj executed. We as- 
sume that each agent is provided with an interaction model 
X = {ri, r2, ■ ■ ■ r n } containing some configured protocols 
(pi . . . Pm) some of which can be introduced at runtime and 
for each protocol pi a set of roles {n, T2, . . . rfc} this agent 
can play during interactions based on pi. 

In the following two sections, we elaborate on our solu- 
tion to the selection problem. 

3 Joint Protocol Selection 

Once an agent locates the description of a collaborative task, 
it finds out a set of protocols needed to execute this task 
which it refines to a sub set of protocols whose initiator 
roles are configured inside its interaction model. Moving 
from collaborative tasks models to protocols' requires the 
agents to analyse both models and detect their adequacy. In 
this paper we assume that agents are able to examine tasks 
and protocols models and relate the first ones to the sec- 
ond ones. After moving from task to protocols the initia- 
tor agent should identify all the potential participant agents 
for the determined protocols. Both steps provide the initia- 
tor agent with a sparse matrix: potential participants linked 
to protocols. These potential participant agents are thus con- 
tacted whether at the same time or one after the other and 
are required to validate a protocol. To contrast the messages 
exchanged during the joint selection and those exchanged 
during normal interactions, we proposed some performa- 
tives which we informally describe here bellow: 

call-f or-collaboration the sender of this perfor- 
mative invites the receiver to take part in a protocol de- 
scribed in the content field. 

unable-to-select the sender of this performative in- 
forms the receiver that it cannot play a participant 
role in the related protocol. The in-reply-to and 
reply-with fields help relate this message to a prior 



call-f or-collaboration. The reasons why an 
agent may reply this performative, though identified as 
a potential participant for the protocol, are (1) its au- 
tonomy since it may not want to execute this protocol 
at this moment and (2) some errors in some fields. 

stop-selection the sender of this performative asks 
the receiver to stop the selection process this message 
is linked to. 

ready -to-select the sender of this performative no- 
tifies the receiver of the participant roles it can be en- 
acting regarding the protocol description it received. 
All the participant roles in any protocol compatible 
with the current one can be listed. This grouping not 
only reveals by order of preference the roles the sender 
commits in playing but it also avoid going back and 
forth about protocols sharing the same background. 
Roles of protocols are compatible when they can ex- 
ecute safe interactions albeit the difference in their re- 
spective specifications. As an example the initiator role 
of CNP can interact with either the participant role of 
CNP or that of Iterated CNP (ICNP [5]). While the 
initiator of ICNP can't interact with the participant of 
CNP because of the probable iterations. 

notif y-assignment the sender of this performative 
informs the receiver about the role the latter has been 
assigned to in the jointly selected protocol. The as- 
signed role is one among those the receiver priorly 
committed in playing. 

Whatever protocol category the selection is concerned 
with, we can describe the joint selection messages exchange 
sequence as follows: 

1. the initiator agent sends acall-for-collaboration 
encapsulating a protocol's description. 

2. Each participant agent can reply with an 
unable-to-select driving the initiator agent to 
stop the selection process between both agents by 
sending a stop-selection. 

3. Each participant agent can also reply with a 
ready-to-select. In this case, the initia- 
tor agent parses the participant's proposals and adopts 
one of them sending a notif y-assignment or re- 
ject all the proposals sending a stop-selection. 

In the remainder of this section we detail the joint selec- 
tion method for each class of protocol. 

3.1 Inside the Joint Protocol Selection 
3.1.1 1-1 Protocols 

In the dynamic 1-1 protocols selection, the aim of the ini- 
tiator agent is to early find out a solution, a couple (a,i,pj) 



where is one of the potential participant agents formerly 
identified and pj one of the 1-1 protocols determined for the 
current task. In the midst of the solution search is the ma- 
trix's exploration. Hence, it behoves the initiator agent to 
explore the matrix traversing protocols or potential partici- 
pant agents. In the protocol-oriented exploration, the initia- 
tor selects a protocol and iterates through the set of agents 
which it identified for this protocol and retains one that fits 
the protocol. As soon as an agent is determined the selec- 
tion process successfully completes. Otherwise, the itera- 
tion proceeds until there is no more protocol to select. Anal- 
ogously, in the agent-oriented exploration the initiator se- 
lects an agent and delves into its protocols' set looking for 
one they can execute together. Whatever exploration the ini- 
tiator adopts, it should overcome the matrix sparsity by se- 
lecting as next element (protocol or agent) the one holding 
the least sparse vector. 

Consider, by way of illustration, a query agent qi 
which is requested to execute a task t\\ "find out a doc- 
ument exhibiting the following characteristics: (lan- 
guage= 'English', content= 'plain/text')". Protocols and po- 
tential participant agents identifications for t\ lead to the 
matrix given in table 1 where a cross in a cell [l,c] in- 
dicates that the agent at column c can play a partici- 
pant role in the protocol at line I. This matrix reveals 
that qi has identified IPS (an Incremental Problem Solv- 
ing protocol where a problem submitter -initiator- and 
its solver -the participant- progressively find out a so- 
lution to a given problem) and Request. A diagram- 
matic representation of IPS is given in figure 1. In addi- 
tion, qi identified seven potential participant document 
agents di . . . d-j. qi adopts a protocol-oriented explo- 
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ration and selects IPS (the least sparse vector). There- 
fore, it will try to validate IPS with di, d2, cU, ds 
or d7. If qi receives a ready-to-select in re- 
ply to a prior call-f or-collaboration, it explores 
the list of preferred roles and as soon as it finds the partici- 
pant role of IPS or Request it notifies its agreement with a 
notif y-assignment. If qi identified more than these 
protocols and a role of any of them is pointed out in the par- 
ticipant's ready-to-select, this protocol will be 
adopted. In the case it didn't find out any role it ex- 
pects or it received an unable-to-select, qi replies 
with a stop-selection and as long as there are still un- 
explored potential participant agents for IPS, qi will con- 
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Figure 1. Incremental Problem Solving Proto- 
col 



tinue contacting them. In absence of solution when the po- 
tential participants' set has been thoroughly explored for a 
protocol, the same process is taken again upon another pro- 
tocol if there is any. In case no solution has been found and 
no more protocol and participant can be explored, the dy- 
namic protocol selection fails and the subsequent task 
remains not executed. 

3.1.2 1-1 N Protocols 

A solution to the dynamic 1-1 N Protocols selection prob- 
lem is a couple (A,Pj) where A is the set of participant 
agents and pj the protocol to use. For this category of pro- 
tocols the matrix is explored only in a protocol-oriented 
way since all the identified agents for a protocol are con- 
tacted at the same time. Once all the contacted agents have 
replied, the initiator agent should select a common protocol 
for the agents (generally for a part of them) which replied 
a ready-to-select. We devised several strategies to 
perform this selection but here we only describe one, the 
largest set's strategy, which looks for the role most agents 
selected. If there exists a role rj that all the agents pointed 
out, then this one is selected for all the agents which replied 
a ready-to-select. Otherwise, we look for a role that 
will involve the largest set of agents. Therefore, we con- 
struct an array where each index i contains a collection of 
all the roles which exactly i agents candidated for. As we 
didn't succeed in finding out a role for all the n agents which 
sent aready-to-select, the highest index in this array 
points to a collection of roles that exactly n — 1 agents can- 
didated for. We traverse the array from the highest index 
down to the lowest. While exploring index k, if the collec- 
tion of roles is not empty, we represent for each role r t the 
set e t of agents which candidated for it. 

1 . If all the a are equal, then we randomly select a r p and 



adopts its corresponding e p as the participant agents' 
set. The solution is then e p and the relevant protocol 
r p belongs to. 

2. Otherwise: 

(a) For each e l7 we compute the difference 
with the union of all the sets except e t : 
dif t = (e, - (J{ej}, j ^ i). Then, we se- 

3 

lect the largest dif l . 

(b) If no decision could be made, we save all the e l 
(only for the highest index) and proceed on our 
iteration. 

After a solution has been found for an index k, we check 
whether some sets have not been saved for a higher index. 
If no sets were found the final solution is the one at hand. 
Otherwise, we select from the latters the set whose intersec- 
tion with the currently selected set is the largest. If no solu- 
tion has been found we iterate through the selection process 
changing protocols. 

3.1.3 1-N Protocols 

A solution to the dynamic 1-N Protocols selection prob- 
lem is a triple (A,Pj,m) where A is the set of par- 
ticipant agents, pj the protocol to use and m an as- 
sociative array mapping each agent to the role(s) it 
will play in the protocol. Here again, the matrix is ex- 
plored only in a protocol-oriented way. The initiator 
agent a t waits for all the participants' replies and gath- 
ers the ready-to-select messages. The roles are clus- 
tered following the protocols they belong to and the 
protocols which have not been identified by the initia- 
tor agent are eliminated. For each protocol p, a t maps 
each role r to a set of agents which candidated for it: 

candidates(rj) = [_J{a/c}. If candidates' j) = 0, the 
k 

protocol r 3 belongs to is no more considered in the selection 
process. Moreover, as there exists several participant roles 
in 1-N protocols, some of them may receive their first mes- 
sage from other participant roles. Thus, we introduce a new 
relation, father, given two roles r\ and r2 of a 1-N protocol, 
ri = father'^) \= n is the sender of the r' 2 s first message. 
For each protocol retained after the candidates sets con- 
struction, the initiator agent constructs a tree t wherein 
nodes are the roles of the protocol. A node r m is child 
of another node r„ if r„ = father(r m ). t is traversed in a 
breadth-first way and for each node r 3 of t an agent a 3 is as- 
signed to r 3 from candidates' 3 ). Assigning a role to an 
agent can be performed by any well known resource allo- 
cation algorithm (ex election). This assignment is achieved 
for all the trees and the initiator agent uses a strategy to se- 
lect one of the totally assigned trees. An improvement dur- 
ing the roles assignment is to avoid situations where the 



same agent plays several roles in a protocol. Thus, when 
candidates is a singleton, its only one agent is re- 
moved from all other candidates sets it appears in 
when these are not singletons. As well, while explor- 
ing t, once a role has been assigned to an agent we should 
remove this agent from all the candidates sets it ap- 
pears in provided these are not singletons. The singleton 
criterion may guide a tree selection strategy. 

3.2 Beyond the joint protocol selection 

The joint protocol selection mechanism does not apply to all 
interaction contexts. One evident issue is that generic pro- 
tocols are thought to be invariably specified in the MAS. 
However, the only one aspect that remains invariable in 
generic protocols' specification is the description of ex- 
changed messages which is imposed by communication 
languages (KQML, FIPA ACL) and embedded in the proto- 
cols' specification. Hence, there is no guarantee for generic 
protocols to be specified in a unique formalism and agents 
might fail to interpret some of the formalisms used to spec- 
ify generic protocols in the MAS. Particularly, plugging het- 
erogeneous sub-systems together in a MAS increases the 
risk for multiple generic protocols specification formalisms. 
The joint protocol selection then falls short in a MAS where 
generic protocols are specified in several formalisms and 
agents are unable to interpret all those formalisms. In ad- 
dition, there are also situations where agents do not always 
trust one another. Then, basing protocols selection on spec- 
ifications exchange becomes unsafe. 

To address these drawbacks, we developed an individual 
protocol selection method. 

4 Individual Protocol Selection 

This selection form is carried out concomitantly to the 
targeted interaction. Likewise the joint protocol selection 
form, the initiator agent is in charge of starting the selec- 
tion process when it locates a collaborative task's descrip- 
tions. It finds out some protocols which comply with the 
task's descriptions and wherein it can play an initiator role. 
The initiator agent may adopt a static behaviour during this 
selection by choosing a protocol among the candidates, in 
this case, the strategy it adopts is required to be fair. It may 
also be given the possibility to exhibit dynamic behaviours 
by changing protocols in order to address occurring incon- 
sistencies. In this paper we consider the first case. 

The initiator agent sends the initial message m of the 
selected protocol p t to one or several potential partici- 
pant agents. m actually denotes a need for a new in- 
teraction and any agent which receives it selects a par- 
ticipant role r } which starts with m 's reception. Hence, 



each participant agent a 3 constructs the collection of can- 
didate roles r which we refer to in the remainder of this 
section as collection(aj, tk). The roles are then selected 
from collection{a 3 , tk) and instantiated so that the inter- 
action can take place. The individual protocol selection, al- 
though more sophisticated and powerful, can lead to inter- 
action inconsistencies. Indeed, as individually selected roles 
may mismatch, the exchanged messages' content or struc- 
ture (performative, ontology, language, etc.) may be wrong. 
Thus, we provide agents with techniques to anticipate such 
errors by checking incoming messages over structure and 
content compliance. When collection(a 3 , tk) is a singleton, 
the only one role is instantiated in order to interact. If any 
error occurs during the interaction no recovery would have 
been possible. Dynamically selecting protocols is more ap- 
pealing when the collection(a 3 ,tk) contains several roles. 
In this case we explore collection(a 3 ,tk) either sequen- 
tially or in parallel. In this paper, we only describe individ- 
ual 1-1 protocols selection since the selection mechanism is 
quite similar for the other two types of protocols and only 
some extensions are required to fit the specificity of these 
protocols. 

4.1 Sequential Roles Instantiation 

In the purpose of starting an interaction or replacing a fail- 
ing role during an interaction, a participant agent randomly 
(or using another strategy we'll define later) selects roles 
from the collection one after the other until there is no avail- 
able role to select or the interaction eventually safely ends 
up. Once selected, roles are removed from the collection 
in order to avoid selecting them anew during the same in- 
teraction. When a message is wrong the participant agent 
must recover from this error by replacing the failing role. 
The recovery process lies on the interaction's journal where 
agents log the executed methods and the related events (in- 
put: events which fired the method, and output: events gen- 
erated by the method's execution). Each method and its 
events form a record. The following four steps define the 
error recovery process: 

1 . If an agent detects an error, it notifies its interlocutor; 

2. a 3 then purges collection(a 3 ,tk) and selects another 
role; 

3. a 3 computes the point where the interaction should 
continue at in the newly selected role and notifies the 
initiator; 

4. Both agents update their journals by erasing the wrong 
records and the interaction proceeds. 

The participant role replacement during error recovery can 
require the initiator agent to roll some actions back in order 
to synchronise with the newly instantiated role. To purge 

collection(a 3 , tk), a 3 : 



1. Removes from collection{a 3 ,tk) all the roles whose 
description, from the beginning of the role to the point 
the error occurs at, does not match the journal; 

2. If the message structure is wrong and the error has 
been detected by the initiator agent, removes from 
collection(aj, t k ) the roles that generated the wrong 
message. If the error has been detected by a 3 itself, it 
removes from collection(a 3 , tk) the roles that can't re- 
ceive the claimed erroneous message; 

3. If the message content is wrong and if the er- 
ror was detected by the initiator agent, removes 
from collection{a 3l tk) the roles that cannot gener- 
ate the same message structure at the point the er- 
ror occurs at and removes from collection(a 3 ,tk) 
the roles that use the same method as the one caus- 
ing the error. If the error was detected by the par- 
ticipant agent, removes from collection(a 3 , tk) the 
roles that do not receive the same message struc- 
ture at the point the error occurred at and also re- 
moves from collection(a 3 , tk) the roles that do not 
receive the same message content at the point the er- 
ror occurred at 

Since it's no use checking the content when the message 
structure is wrong, structure compliance is checked prior to 
content's. When a role does not comply with the current 
execution, it is removed from collection(a 3 , tk). Roles re- 
moval actually consists in marking them so that they can no 
more be instantiated in the current interaction. Then, from 
the updated collection(a 3 , tk), a 3 selects a new role follow- 
ing the strategy described hereby: 

1. If the message content is wrong: (a) for each role of 
collection(a 3 , t k ), construct the set of messages (gen- 
erated or received) at the point the error occurred at; 
(b) withdraw from these sets the message that caused 
the error; (c) compare these sub sets and select the 
weakest one; Then the role the selected sub set orig- 
inates from is instantiated. The weakest messages sub 
set is the one containing the higher number of weak 
messages. Weak messages are those which lead to in- 
teraction termination; these messages are potentially 
weaker than those which continue the interaction. The 
reason why we prefer the weakest messages sub set 
is that we wish to avoid producing another message 
than the "structurally" correct one we generated pri- 
orly. When there are several sub sets candidate for se- 
lection or when there are none, a role is randomly se- 
lected. 

2. If the message structure is wrong: randomly select a 
role in the collection(a 3 , tk). 

Once a new role has been selected, the participant agent 
might expect to continue its execution from the point the er- 



ror occurred at. However, doing so can bring inconsisten- 
cies in the interaction execution because the roles, though 
enacted by the same agent, do not necessarily use the same 
methods. These inconsistencies could be avoided by look- 
ing for methods of the new role which follow the same se- 
quence order as in the journal from the starting point. This 
set of methods won't be re-executed. We represent the meth- 
ods of the new role as nodes of a directed graph wherein an 
edge mimj means that method rrij can be executed imme- 
diately after m^ completes and the conditions for its exe- 
cution hold. Algorithm 1 achieves this computation and re- 
turns the recovery points for both the initiator and the par- 
ticipant. In this algorithm, i is the number of the latest mes- 



Algorithm 1 recovery points computation 

Input: Journal = the participant's journal 
Input: Graph = the new role's methods graph 
Result: Initiator and participant recovery points 

stop <— false; 

i <- 1; 

j<-i; 

mth_journal < — readjniujournal); 
mth_graph < — get_init_node(graph); 
if mth_journal ^ mth_graph then 

stop <— true; 
end if 

while stop = false do 

mth_journal <— Succ(mth_journal); 
if mth_journal = null then 

stop < — true; 
else if mthjournal £ follow(mth_graph) then 

mth_graph mth.journal; 

if Input is Message then 

i <— j+1; 
end if 
else 

stop <— true; 
end if 
end while 

initiator recovery point: i; 
participant recovery point: j; 



sage the initiator should be considering it has sent to the par- 
ticipant and j the point where the participant is to start exe- 
cuting its new role from. The third event type considered in 
the journal (data value change in addition to message emis- 
sion and reception) accounts for the difference between i 
and j. Once the initiator receives i, it looks for the record in 
its journal representing the i th message it sent to the partic- 
ipant. All the records following this one will be erased from 
the journal. The participant also updates its journal in quite 
the same way basing on j. 

Suppose di wants to identify the language its docu- 
ment is written in; this task (t 2 ) requires an interaction with 
a rule agent. We assume di finds out a protocol which 
starts with an ask-one emission and expects a tell. Con- 
sider di contacted a rule agent ci whose interaction model 
is partially depicted in figure 2. In this figure, for exam- 
ple the given portion of n can be interpreted as: n re- 
ceives an ask-one and can reply an insert or a sorry. 
collection^!, t%) = {r 1; r 2 , r 3 , r 4 }. 




Figure 2. agent c's interaction model 



• Whatever role ci selects, if it replies a sorry the inter- 
action will end up, may be prematurely -the first mes- 
sage has not been validated yet. To get sure it's not 
so di issues a warning: "May be premature interac- 
tion termination!". c\ tries to select another role and 
the interaction proceeds or definitely stops. 

• If ci selected and sent a tell whose content is wrong 
di notifies cia wrong message content error, ci then 
stops r4, purges its coUection{a 3 , tk) by removing ri 
(since it cannot generate a t e 1 1 at the error location), 
selects r3 because it corresponds to the weakest sub set 
and computes the recovery points: i = j = Recftl. ci 
updates its journal and replies anew to the ask-one. 

In order to avoid inconsistencies at the end of interac- 
tions, we require both agents to explicitly notify each other 
the protocol's termination. Instead of selecting roles on the 
basis of messages they can generate, it sounds to select them 
on the basis of messages they really generated. This is pos- 
sible only if all candidates roles are instantiated at the same 
time. This parallel roles instantiation is only known from 
the participant agent; the initiator agent still has the percep- 
tion of a sequential roles instantiation. 

4.2 Mixed Roles Instantiation 

All the roles a 3 identified in collection(a 3 , tk) are instanti- 
ated at the same time. They handle the received message and 
generate their reply messages which are stored in a control 
zone (C z ); C z also contain the messages which are destined 
to currently activated roles. The roles are then deactivated. 
Only one message m,k is selected from C z and sent to the 
initiator. This selection can be performed following several 
strategies. For example, the participant agent can randomly 
select a message among those which don't shorten the inter- 
action. Therefore, if an insert, a sorry, an error and 
a tell are generated in reply to an ask-one, insert 
and tell will be preferred to sorry and error, and the 
random selection will be performed between the first two 
messages. After a message nik has been selected, all the 
roles which generated a message of the same structure and 
content are activated. In this instantiation mode, when an 
error occurs, the participant agent recovers from it by stop- 
ping the wrong roles and by reactivating one or several other 
roles. Thus, if an error occurs on rri]~: 



All the activated roles are stopped; 

If the message structure is wrong: all the nik as well as 
the messages having the same structure are removed 
from C z and their roles are stopped. The participant 
selects another message my following the same prin- 
ciple as TOfc's selection. 

3. If the message content is wrong: all the m k messages 
as well as those having the same content pattern are 
removed from C z and their roles are stopped. The par- 
ticipant selects another message my having the same 
structure but a different content pattern. 

When some roles stayed activated, they all generate their 
messages. If the messages have the same structure and con- 
tent, all these roles remain activated. Otherwise, only one 
message is selected and all the roles whose message have 
not been selected are deactivated. If all the previously ac- 
tivated roles have been stopped, the participant agent reac- 
tivates the most recently deactivated role but cares about 
early interaction termination. When there are more than one 
such roles, they all are reactivated. The participant role reac- 
tivation, might require the initiator to roll some actions back 
to a recovery point. An algorithm similar to algorithm 1 per- 
forms the recovery points computation for both the initiator 
and participant. For each role the algorithm is applied, con- 
sidering the roles' current execution, and the final recovery 
point is the earliest. 

5 Related Work 

Protocols selection in agents interactions design is some- 
thing generally done at design time. Indeed, most of 
the agent-oriented design methodologies (Gaia [7] and 
MaSE [3] to quote a few) all make designers decide which 
role agents should play for each single interaction. How- 
ever dynamic behaviours and openness in MAS demand 
greater flexibility. 

To date, there have been some efforts to overcome this 
limitation. [4] introduces more flexibility in agents' coor- 
dination but it only applies to planning mechanisms of the 
individual agents. [2] also proposes a framework based on 
multi-agent Markov decision processes. Rather than identi- 
fying a coordination mechanism which suits best for a sit- 
uation, this work deals with optimal reasoning within the 
context of a given coordination mechanism. [1] proposed a 
framework that enables autonomous agents to dynamically 
select the mechanism they employ in order to coordinate 
their inter-related activities. Using this framework, agents 
select their coordination mechanisms reasoning about the 
rewards they can obtain from collaborative tasks execution 
as well as the probability for these tasks to succeed. 

The main requirement the selection process faces in pro- 
tocol based coordination mechanisms is whether or not 



there exists in the agent's interaction model roles capable of 
supporting the desired interaction. To fill this void, we pro- 
posed a method to enable agents to dynamically select pro- 
tocols basing on their interaction capacities. 

6 Conclusion 

Designing agents for open and dynamic environments is 
still a challenging task, especially in regard to protocol 
based interactions. Two main concerns arise from interac- 
tions modelling and design in such systems. First, how in- 
teractions which are based on generic protocols are config- 
ured so that consistent messages exchange can take place? 
Second, does it sound that designers always decide which 
protocols and roles to use every time an interaction is asked 
for? We address both issues by developing several methods. 
In this paper we focus on the second concern. We argued 
that due to openness and dynamic behaviours more flexi- 
bility is needed in protocols selection. Furthermore, in the 
context of complex applications demanding multi-protocols 
agents, moving from static to dynamic protocol selection 
greatly increases such systems' efficiency and properly han- 
dles the situation tightly related to openness where all the 
protocols are not known at design time. Thus, we enabled 
agents to dynamically select protocols upon the prevailing 
circumstances. 

One outcome of the dynamic protocol selection is that 
the protocols to use are no more hard-coded in all agents 
source code. Rather, programmers mention collaborative 
tasks descriptions in the initiator agent's source code only 
making the latter in charge of firing the interaction. Agents 
are given two ways to select protocols. First, the initiator 
agent and all (or a part of them) the potential participant 
agents it identified can join together and share information 
and preferences about the protocols at hand in order to se- 
lect a protocol and assign a role to each agent. Second, 
agents are given the possibility to individually select their 
protocols and roles anticipating errors. We focus on two 
types of errors: wrong message structure and wrong mes- 
sage content. As roles replacement are performed as soon as 
an anomaly is detected, we constrain actions executed dur- 
ing interactions to be reversible and not to render critical 
side effect. Furthermore, when there are several candidate 
protocols in the individual protocol selection, we developed 
two exploration mechanisms for these candidates: (1) a se- 
quential exploration and (2) a mixed exploration modes. 

Both methods have been proposed and tested in the con- 
text of a European project dedicated for information filter- 
ing. They proved their usefulness to efficiently manage the 
multiple interactions that take place between agents. In this 
paper, we don't provide the results we obtained from the 
application of these methods since they need to be inter- 
preted and compared to static selection cases. In the bar- 



gain, our aim was to describe the theoretical basis of a dy- 
namic protocols selection method. Our method intensively 
benefits from the agents' capacity to interpret, relate and up- 
date models embedded inside them. 
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